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(57) Abstract: A multi-protocol media storage device operates according to both the AV/C Command Set and the FCP protocol 
to record and retrieve data in an isochronous format and the SBP-2 protocol to record and retrieve data in an asynchronous format. 
Isochronous data is recorded on the media storage device on AV tracks according to the AV/C Conunand Set. Asynchronous data 
is recorded on the media storage device in sections called asynchronous spaces. Additionally, isochronous data is recorded in a 
portion of an asynchronous space as described in one or more operation request blocks delivered according to the SBP-2 protocol. 
The AV tracks and the asynchronous spaces are each preferably numbered with a unique integer value. A management operation 
request block (ORB) includes a function field that can have a value indicating that the request is a manage asynchronous space 
request. Within a manage asynchronous space request a sub-function field indicates that the request is a create, delete or query 
asynchronous space request. Command ORBs having a request format field value of "O" are performed within the lowest numbered 
asynchronous space. Command ORBs having a request format field value of "1" are performed within an indicated asynchronous 
space. Previously recorded data within either an AV track or an asynchronous space can be accessed using both the FCP protocol 
and the SBP-2 protocol. 
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A MULTI-PROTOCOL MEDIA STORAGE DEVICE 

IMPLEMENTING PROTOCOLS OPTIMIZED FOR STORING 

AND RETRIEVING BOTH ASYNCHRONOUS AND ISOCHRONOUS DATA 

5 FIELD OF THE INVENTION : 

The present invention relates to the field of writing data to and reading data from 
media storage devices. More particularly, the present invention relates to the field of 
writing both asynchronous and isochronous data to media storage devices and reading both 
asynchronous and isochronous data fi*om media storage devices. 

10 

BACKGROUND OF THE INVENTION : 

The IEEE 1394-1995 standard, "1394 Standard For A High Performance Serial 
Bus," is an international standard for implementing an inexpensive high-speed serial bus 
architecture which supports both asynchronous and isochronous format data transfers. In 

15 addition, the IEEE 1394-1995 bus has a universal clock called the cycle timer. This clock 
is synchronized on all nodes. Isochronous data transfers are real-time transfers which take 
place based on the universal clock such that the time intervals between significant instances 
have the same duration at both the transmitting and receiving applications. Each packet of 
data transferred isochronously is transferred in its own time period. An example of an 

20 ideal application for the transfer of data isochronously would be from a video recorder to a 
television set. The video recorder records images and soimds and saves the data in discrete 
chunks or packets. The video recorder then transfers each packet, representing the image 
and sound recorded over a limited time period, during that time period, for display by the 
television set. The IEEE 1394-1995 standard bus architecture provides multiple 

25 independent channels for isochronous data transfer between applications. A six bit channel 
number is broadcast with the data to ensure reception by the appropriate application. This 
allows multiple applications to simultaneously transmit isochronous data across the bus 
structure. Asynchronous transfers are traditional reliable data transfer operations which 
take place as soon as arbitration is won and transfer a maximum amoimt of data from a 

30 source to a destination. 

The IEEE 1394-1995 standard defines a high-speed serial bus for interconnecting 
digital devices thereby providing a universal I/O connection. The IEEE 1394-1995 
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Standard defines a digital interface for the application thereby eliminating the need for an 
application to convert digital data to analog data before it is transnutted across the bus. 
Correspondingly, a receiving application will receive digital data from the bus, not analog 
data, and will therefore not be required to convert analog data to digital data. The cable 
5 required by the IEEE 1394-1995 standard is very thin in size compared to other bulkier 
cables used to connect such devices in other connection schemes. Devices can be added 
and removed from an IEEE 1394-1995 bus while the bus is operational. If a device is so 
added or removed the bus will then automatically reconfigure itself for transmitting data 
between the then existing nodes. A node is considered a logical entity with a unique 
10 address on the bus structure. Each node provides in a standard address space, an 

identification ROM, a standardized set of control registers and in addition, its own address 
space. 

The IEEE 1394-1995 standard defines a protocol as illustrated in Figure 1. This 
protocol includes a serial bus management block 10 coupled to a transaction layer 12, a 

15 link layer 14 and a physical layer 16. The physical layer 16 provides the electrical and 
mechanical connection between a device and the IEEE 1394-1995 cable. The physical 
layer 16 also provides arbitration to ensure that all devices coupled to the IEEE 1394-1995 
bus have arbitrated access to the bus as well as actual data transmission and reception. The 
link layer 14 provides data packet delivery service for both asynchronous and isochronous 

20 data packet transport. This supports both asynchronous data transport, using an 

acknowledgement protocol, and isochronous data transport, providing an un-acknowledged 
real-time guaranteed bandwidth protocol for just-in-time data delivery. The transaction 
layer 12 supports the protocols necessary to complete asynchronous data transfers, 
including read, write and lock. The serial bus management block 10 contains an 

25 isochronous resource manager for managing the resources associated with isochronous data 
transfers. The serial bus management block 10 also provides overall configuration control 
of the serial bus in the form of optimizing arbitration timing, guarantee of adequate 
electrical power for all devices on the bus, assignment of the cycle master, and allocation 
of isochronous channel and bandwidth resources. 

30 The AV/C Command Set is a command set used for transactions to and from 

consumer audio/video equipment over an IEEE 1394-1995 serial bus. This AV/C 
command set makes use of the Function Control Protocol (FCP) defined by IEC-61883, the 
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ratified international standard for the transport of audio/video command requests and 
responses. AV/C commands are transmitted through AV/C transactions. An AV/C 
transaction consists of one AV/C command frame addressed to the target node's 
FCP_Command register and zero or more AV/C response frames addressed to the 
5 requesting node's FCP_Response register. 

Each audio/video unit or subunit can implement a subset of the AV/C command set. 
An unsupported command received by an audio/video unit is rejected with a not 
implemented response. Support for the different commands is characterized as mandatory, 
recommended, optional and vendor-dependent. A mandatory command is supported by any 

10 audio/video device that claims compliance with the AV/C command set and that 

implements the audio/video unit or subunit type for which the command is defined. An 
AV/C compliant device is identified by an entry within its configuration read-only memory 
(ROM). A recommended command is optional for an AV/C compliant device, but 
represents a basic functionality, such as video and audio insert modes for a VCR subunit' s 

15 record command. If the device supports a unit or subunit type that has the functionality 

corresponding to the command, it is recommended that the command be implemented. An 
optional command is optional for an AV/C compliant device. Support for and 
interpretation of a vendor-dependent command are defined by the device vendor. 

AV/C commands are grouped into four command types including control, status, 

20 inquiry and notify command types. A control command is sent by a controller to another 
audio/video device, the target, to instruct the target to perform an operation. A target that 
receives a control command will return an AV/C response frame including either a not 
implemented, accepted, rejected or interim response code. The target will return a not 
implemented response code when the target does not support the control command 

25 specified or the command is addressed to a subunit not implemented by the target. The 
target will return an accepted response code when the target implements the control 
command specified and the current state of the target permits execution of the command. 
The target will return a rejected response code when the target implements the control 
command specified but the current state of the target does not permit execution of the 

30 command. The target will return an interim response code if the control command 

specified is implemented by the target, but the target is unable to respond with either an 
accepted or rejected response code immediately. Unless a subsequent bus reset causes the 




wo 01/29679 PCT/USOO/28744 

AV/C transaction to be aborted, the target will ultimately return a response frame with an 
accepted or rejected response code after returning an interim response code. 

A status command is sent by a controller to an audio/video device to request the 
current status of the target device. Status commands may be sent to either audio/video 
5 units or subunits. A target that receives a status command will return an AV/C response 
frame including either a not implemented, rejected, in transition or stable response code, A 
target will return a not implemented status response code when the target does not support 
the status command specified or the command is addressed to a subunit not implemented 
by the target. A target will return a rejected status response code when the target 

10 implements the status command specified but the target state does not permit the return of 
status for the command. The target will return an in transition status response code when 
the target implements the status command specified, but the current state of the target is in 
transition. The target will return a stable status response code when the target implements 
the status command specified and the information requested is reported in the values in the 

15 AV/C response frame. 

An inquiry command is used by a controller to determine whether or not a target 
audio/video device supports a particular control command. A controller can reUably use 
inquiry commands to probe the capabilities of a target, since the target shall not modify 
any state nor initiate any command execution in response to an inquiry command. A target 

20 that receives an inquiry command will return an AV/C response frame including either an 
implemented or a not implemented response code. An implemented response code notifies 
the controlling node that the corresponding control command specified is implemented by 
the target audio/video device. A not implemented response code notifies the controlling 
node that the corresponding control command specified is not implemented by the target 

25 audio/video device. 

A notify command is used by a controller to receive notification of future changes 
in an audio/video device's state. Responses to a notify command will indicate the current 
state of the target and then, at some indeterminate time in the future, indicate the changed 
state of the target. A target that receives a notify command will return an immediate 

30 response frame including either a not implemented, rejected or interim response code. A 
target will return a not implemented response code when the target does not support the 
notify command specified or the command is addressed to a subunit not implemented by 
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the target. A target will return a rejected response code when the target implements event 
notification for the condition specified but is not able to supply the requested information. 
A target will return an interim response code when the target supports the requested event 
notification and has accepted the notify command for any future change of state. The 
5 current state is indicated by the data returned in the response frame. At a future time, the 
target will then return an AV/C response frame with either a rejected or changed response 
code. 

The AV/C Disk Subunit Enhancements For Hard Disk Drive Specification is a 
technical specification of the 1394 Trade Association which includes enhancements to the 

10 AV/C Command Set for managing the storage and retrieval of audio and video (AV) 

content to and from hard disk drive devices. Under this AV/C Disk Subunit specification, 
AV content is stored on a hard disk drive in an AV track. An AV track is defined as a 
sequence of recorded data and is described by an AV/C object entry. Each AV track is 
made up of a number of AV frames. An AV frame is a uniquely identifiable section of an 

15 AV track. An AV track can be separated into multiple sections called AV segments. AV 
segments are uniquely identifiable sections of an AV track and can be specified as 
parameters in AV commands. An AV packet is an accessing unit for an AV track. 

A traditional hard disk drive records data received over the IEEE 1394-1995 serial 
bus and plays it back over the IEEE 1394-1995 serial bus according to commands received 

20 from an external controller using a protocol such as the serial bus protocol 2 (SBP-2). The 
external controller is referred to as an initiator and provides command data structures to the 
hard disk drive referred to as a target which inform the hard disk drive where on the media 
the data is to be written, in the case of a write operation, or read from, in the case of a 
read operation. All initiator requests for actions by the target device are expressed within 

25 operation request blocks (ORBs) fetched by the target device using read transactions. Each 
ORB within the SBP-2 protocol has a format as illustrated in Figure 2. The notify bit n 
advises the target device whether or not notification of completion of the operation is 
required. When the notify bit n has a value equal to "0", the target device may elect to 
suppress completion notification except when there is an error. When the notify bit n has a 

30 value equal to "1", the target device always stores a status block in the memory of the 

initiator device to notify the initiator of completion of the operation. The request format 
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field rq_fint specifies the format of the ORB. The following formats for the request format 
field rq_fiiit are defined as illustrated below in Table I. 



Value 


ORB Format 


0 


Format specified by SBP-2 


1 


Reserved 


2 


Vendor-dependent 


3 


Dummy (NOP) request format 



TABLE I 



10 

A request format field rq_fint value of "0" indicates that the ORB has a format specified 
by the SBP-2 protocol. A request format field rq_fint value of "2" indicates that the ORB 
has a format that is vendor dependent. A request format field rq_fmt value of "3" indicates 
that the ORB has a dummy request format. The request format field rq_fint value of "1" is 

15 reserved for fiiture standardization. 

A management ORB is a 32-byte data structure having a format as illustrated in 
Figure 3. For a management ORB, the notify bit n has a value of "1" and the request 
format field rq^fmt has a value of "0". The Amotion field within the management ORB 
specifies the management function requested, as defined by the functions listed below in 

20 Table IL 
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10 



15 



Value 


Management Function 


0 


LOGIN 


I 


QUERY LOGINS 


2 


Reserved for future standardization 


3 


RECONNECT 


4 


SET PASSWORD 


5-6 


Reserved for future standardization 


7 


LOGOUT 




Reserved for future standardization 




ABORT TASK 




ABORl I ASK bbl 




Reserved for future standardization 




LOGICAL UNIT RESET 


F,6 


TARGET RESET 



A function field value of "0" indicates that the ORB is requesting a login function. 

A function field value of "1" indicates that the ORB is requesting a query login function. 

A function field value of "3" indicates that the ORB is requesting a reconnect fimction. A 
20 function field value of "4" indicates that the ORB is requesting a set password function. A 

fiinction field value of "7" indicates that the ORB is requesting a logout fiinction. A 

fimction field hexadecimal value of "B" indicates that the ORB is requesting an abort task 

fiinction. A fiinction field hexadecimal value of "C" indicates that the ORB is requesting 

an abort task set fimction. A fimction field hexadecimal value of "E" indicates that the 
25 ORB is requesting a logical unit reset function. A fimction field hexadecimal value of "F" 

mdicates that the ORB is requesting a target reset fimction. The fimction field values of 

"2", "5-6", "8-A" and "D" are reserved for fiiture standardization. 

Within the management ORB, the status field status^FIFO contains an address 

allocated for the return of status information generated by the management request. The 
30 remainder of the fields v^ithin the management ORB of Figure 3 are fimction dependent. 

Use of a media storage device, such as a hard disk drive, for storing streams of 

audio and video data is taught in U.S. Patent AppUcation Serial Number 09/022,926, filed 
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on February 12, 1998 and entitled "MEDIA STORAGE DEVICE WITH EMBEDDED 
DATA FILTER FOR DYNAMICALLY PROCESSING DATA DURING READ AND 
WRITE OPERATIONS," which is hereby incorporated by reference. When storing audio 
and video data streams on such a hard disk drive, the available capacity of the device can 
5 be quickly utilized, due to the large amounts of data included in typical audio and video 
data streams. If multiple traditional hard disk drives are utilized to store large streams of 
data, then the user must typically be responsible for management of these storage and 
retrieval procedures. This storage management responsibility adds complexity to operations 
such as record and playback and requires the user to monitor and control storage and 

10 retrieval operations. An automatically configuring storage array which mcludes a plurality 
of media storage devices coupled together within a network of devices is taught in U.S. 
Patent AppUcation Serial Number 09/310,876, filed on May 12, 1999 and entitled 
"AUTOMATICALLY CONFIGURING STORAGE ARRAY INCLUDING A 
PLURALITY OF MEDIA STORAGE DEVICES FOR STORING AND PROVIDING 

15 DATA WITHIN A NETWORK OF DEVICES," which is hereby incorporated by 
reference. 

Currently, isochronous data recorded using the AV/C Command Set can only be 
read using the AV/C Command Set. Correspondingly, asynchronous data recorded using 
the SBP-2 protocol can only be read using the SBP-2 protocol. There is currently no 

20 media storage device which can capture data directly firom an IEEE 1394-1995 enabled 
consumer device using the AV/C Command Set and the isochronous communications 
mechanism, then permit this captured data to be fi-eely read or written using traditional 
personal computer protocols, such as the SBP-2 protocol. Furthermore, there is currently 
no media storage device which can capture data directly from a device using traditional 

25 personal computer protocols, such as the SBP-2 protocol, then permit this captured data to 
be freely read or written using the AV/C Command Set and the isochronous 
communications mechanism. 

SUMMARY OF THE INVENTION : 
30 A multi-protocol media storage device operates according to both the AV/C 

Command Set and the FCP protocol to record and retrieve data in an isochronous format 
and the SBP-2 protocol to record and retrieve data in an asynchronous format. Isochronous 
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data is recorded on the media storage device on AV tracks according to the AV/C 
Command Set. Asynchronous data is recorded on the media storage device in sections 
called asynchronous spaces. Additionally, isochronous data is recorded in a portion of an 
asynchronous space as described in one or more operation request blocks delivered 
5 according to the SBP-2 protocol. The AV tracks and the asynchronous spaces are each 
preferably numbered with a unique integer value. A management operation request block 
(ORB) includes a function field that can have a value indicating that the request is a 
manage asynchronous space request. Within a manage asynchronous space request a sub- 
function field indicates that the request is a create, delete or query asynchronous space 

10 request. Command ORBs having a request format field value of "0" are performed within 
the lov^est nimibered asynchronous space. Command ORBs having a request format field 
value of "1" are performed within an indicated asynchronous space. Previously recorded 
data within either an AV track or an asynchronous space can be accessed using both the 
FCP protocol and the SBP-2 protocol. Additionally, an initiator can provide an ORB to 

15 the target which describes a portion of an asynchronous space in the form of starting 

address and lengths of muhiple discontinuous regions. In this form the target will either 
record to or play firom these portions of the address space using an isochronous data 
transfer. 

In one aspect of the present invention, a method of accessing a media storage 
20 device coupled to one or more devices includes the steps of receiving a command fi^om one 
of the one or more devices, determining if the command is one of an isochronous format 
command and an asynchronous format command, accessing the media storage device in an 
asynchronous format if the command is an asynchronous format command and accessing 
the media storage device in an isochronous format if the command is an isochronous 
25 format command. The media storage device records data in the isochronous format in AV 
tracks and data in the asynchronous format in one or more asynchronous spaces. The 
isochronous format command is preferably an AV/C command according to FCP protocol. 
The asynchronous format command is preferably delivered according to SBP-2 protocol. 
The asynchronous format command includes an operation request block. The operation 
30 request block is associated with a scatter/gather list describing portions of asynchronous 

space on the media storage device to be read or written by isochronous data. The method 
fiuther includes the step of creating an asynchronous space within the media storage device 
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in response to receiving a manage asynchronous space request requesting creation of the 
asynchronous space. The method further includes the step of deleting a previously created 
asynchronous space within the media storage device in response to receiving a manage 
asynchronous space request requesting deletion of the previously created asynchronous 
5 space. The media storage device is preferably a hard disk drive. Communication between 
the media storage device and the one or more devices preferably substantially comphes 
with a version of the IEEE 1394 standard. 

In another aspect of the present invention, a media storage device for storing and 
retrieving data received from one or more devices in response to a command includes an 

10 interface circuit configured to couple to the one or more devices to communicate with the 
one or more devices, a control circuit coupled to the interface circuit to detennine if the 
command is one of an isochronous format command and an asynchronous format command 
and media coupled to the control circuit to record isochronous data received from the one 
or more devices in an AV track in response to an isochronous record command, to record 

15 asynchronous data received from the one or more devices in an asynchronous space in 
response to an asynchronous write command and to retrieve both previously recorded 
asynchronous data and isochronous data. Preferably, the isochronous format command is 
an AV/C command according to FCP protocol. Preferably, the asynchronous format 
command is delivered according to SBP-2 protocol. An asynchronous space is created on 

20 the media in response to a manage asynchronous space request requesting creation of the 
asynchronous space received from one of the one or more devices. The media storage 
device is preferably a hard disk drive. The interface circuit is preferably coupled to the 
one or more devices through a network which substantially complies with a version of the 
IEEE 1394 standard. 

25 In yet another aspect of the present invention, a management operation request 

block for requesting a manage asynchronous space operation within a media storage device 
includes a function field including a first value indicating that the operation request block 
is a manage asynchronous space operation request block and a sub-function field including 
a second value indicating a type of manage asynchronous space request requested in the 

30 management operation request block. The type of manage asynchronous space request is a 
selective one of a create asynchronous space request, a delete asynchronous space request 
and a query asynchronous space request. An asynchronous space is created on the media 
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Storage device in response to a manage asynchronous space request of the type create 
asynchronous space. An existing asynchronous space is deleted on the media storage 
device in response to a manage asynchronous space request of the type delete asynchronous 
space. Information about existing asynchronous spaces on the media storage device is 
5 obtained in response to a manage asynchronous space request of the type query 

asynchronous space. The management operation request block further includes a notify bit 
and a request format field. The management operation request block preferably has a 
format which substantially complies with SBP-2 protocol. The media storage device is 
preferably a hard disk drive. 

10 In still yet another aspect of the present invention, a method of accessing a media 

storage device coupled to one or more devices within a network of devices includes the 
steps of receiving a command from one of the one or more devices, determining if the 
command is one of an isochronous AV/C format command according to FCP protocol and 
an asynchronous format command received according to SBP-2 protocol, accessing the 

15 media storage device in an asynchronous format according to the SBP-2 protocol if the 
command is an asynchronous format command and accessing the media storage device in 
an isochronous format according to the FCP protocol if the command is an isochronous 
format command. The method further includes the step of storing isochronous data in 
response to a record isochronous format command within an AV track in the media storage 

20 device. The method further includes the step of creating an asynchronous space within the 
media storage device in response to receiving a manage asynchronous space request 
requesting creation of the asynchronous space. The method further includes the step of 
storing asynchronous data in response to a write asynchronous format command within the 
asynchronous space. The method further includes the step of deleting an existing 

25 asynchronous space within the media storage device in response to receiving a manage 
asynchronous space request requesting deletion of the existing asynchronous space. The 
method further includes the steps of determining if the command is one of an isochronous 
format command received according to a modified SBP-2 protocol and accessing the media 
storage device in an isochronous format if the command is received according to the 

30 modified SBP-2 protocol and requests isochronous handling. The method further includes 
the step of storing isochronous data in response to a command received according to the 
modified SBP-2 protocol. The media storage device is preferably a hard disk drive. 
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Communication between the network of devices preferably substantially complies with a 
version of the IEEE 1394 standard. 

In yet another aspect of the present invention a network of devices includes one or 
more content devices for generating and consuming content data and a media storage 
5 device coupled to the one or more content devices for storing and retrieving the content 
data in response to a command, including an interface circuit coupled to the one or more 
content devices to transmit communications to and receive conmiunications from the one or 
more content devices, a control circuit coupled to the interface circuit to determine if the 
command is one of an isochronous format command and an asjnichronous format command 

10 and media coupled to the control circuit to record isochronous data received from the one 
or more content devices in an AV track in response to an isochronous record command, to 
record asynchronous data received from the one or more content devices in an . 
asynchronous space in response to an asynchronous write command and to retrieve both 
recorded asynchronous data and isochronous data. The network of device further includes 

15 a controller coupled to the interface circuit and to the one or more content devices for 
generating the command and transmitting the command to the interface circuit The 
command can also be received from one of the one or more content devices. The 
isochronous format command is preferably an AV/C command according to FCP protocol. 
The asynchronous format command is preferably delivered according to SBP-2 protocol. 

20 An asynchronous space is created on the media in response to a manage asynchronous 

space request requesting creation of the asynchronous space received from one of the one 
or more content devices. The media storage device is preferably a hard disk drive. The 
interface circuit is preferably coupled to the one or more content devices through a network 
which substantially complies with a version of the IEEE 1394 standard. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS : 

Figure 1 illustrates a protocol defined by the IEEE 1394-1995 standard. 

Figure 2 illustrates a format of an operation request block according to the SBP-2 
protocol. 

30 Figure 3 illustrates a format of a management operation request block according to 

the SBP-2 protocol 
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Figure 4 illustrates an exemplary IEEE 1394-1995 serial bus network of devices 
including a video camera, a video cassette recorder, a settop box, a television, a computer 
and an audio/video hard disk drive according to the present invention. 

Figure 5 illustrates a block diagram of a media storage device according to the 
5 preferred embodiment of the present invention. 

Figure 6 illustrates a format of a modified management operation request block 
according to the preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT : 

10 An audio/video hard disk drive (AVHDD) operates according to both the AV/C 

Command Set and the FCP protocol to record and retrieve data in an isochronous format 
and the SBP-2 protocol to record and retrieve data in an asynchronous format. On the 
AVHDD, isochronous data is recorded on AV tracks according to the AV/C Command Set. 
Each of the AV tracks is numbered with an integer value. Asynchronous data is recorded 

15 on the AVHDD in sections called asynchronous spaces. Each asynchronous space is also 
numbered with an integer value. Preferably, the AV tracks and the asynchronous spaces 
are each numbered with a unique integer value. 

The format of the management operation request block (ORB) within the SBP-2 
protocol is preferably modified for implementation of the present invention. The 

20 management ORB is used create, delete or determine information about asynchronous 
spaces on the AVHDD. Within the management ORB of the present invention, the 
function field can have a value indicating that this request is a manage asynchronous space 
request. Preferably, this value of the function field indicating a manage asynchronous 
space request is equal to one of the reserved values of the function field described above. 

25 The management ORB of the present invention also includes a sub-function field having a 
value indicating that the request is a create asynchronous space request, a delete 
asynchronous space request or a query asynchronous space request. The create 
asynchronous space request is used to create a new asynchronous space within the available 
space on the AVHDD. The delete asynchronous space request is used to delete a 

30 previously created asynchronous space. The query asynchronous space request is used to 
request the target device to return the numbers of the currently existing asynchronous 
spaces. 
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The format of a command ORB within the SBP-2 protocol is also preferably 
modified for implementation of the present invention. If the command ORB includes a 
value in the request format field rq_fmt equal to "0", then the operation is performed 
within the numerically lowest asynchronous space and is treated as a conventional SBP-2 
5 protocol operation. If the command ORB includes a value in the request field rq_fint equal 
to "1", then the operation is performed within the existing asynchronous space 
corresponding to the number indicated within an asynchronous space number field within 
the command ORB. A value of "1" within the request format field rq_fmt of a command 
ORB indicates that the initiator recognizes that the AVHDD is operating according to the 

10 principles of the present invention and can have more than one asynchronous space. 

Isochronous data accesses of the AVHDD using the AV/C Command Set and the 
FCP protocol are performed on AV tracks, as described above. However, an isochronous 
data access using the AV/C Command Set and the FCP protocol can also be performed on 
data within an asynchronous space. Furthermore, an asynchronous data access of data 

15 within an isochronous AV track, can also be performed using the modified SBP-2 protocol. 
In the preferred embodiment of the present invention, the AVHDD does not permit access 
of a copy-protected AV track using SBP-2 protocols. 

Figure 4 illustrates an exemplary network of devices including a video camera 28, a 
video cassette recorder (VCR) 30, a settop box 26, a television 24, a computer 20 and an 

20 audio/video hard disk drive (AVHDD) 36 connected together by IEEE 1394-1995 cables 
40, 42, 48, 50 and 52. The IEEE 1394-1995 cable 50 couples the video camera 28 to the 
VCR 30, allowing the video camera 28 to send data, commands and parameters to the VCR 
30 for recording. The IEEE 1394-1995 cable 48 couples the VCR 30 to the computer 20. 
The IEEE 1394-1995 cable 42 couples the computer 20 to the AVHDD 36. The IEEE 

25 1394-1995 cable 40 couples the computer 20 to the television 24. The IEEE 1394-1995 
cable 52 couples the television 24 to the settop box 26. 

The configuration illustrated in Figure 4 is exemplary only. It should be apparent 
that an audio/video network could include many different combinations of components. 
The devices within such an IEEE 1394-1995 network are autonomous devices, meaning 

30 that in an IEEE 1394-1995 network, as the one illustrated in Figure 4, in which a computer 
is one of the devices, there is not a true "master-slave" relationship between the computer 
and the other devices. In many IEEE 1394-1995 network configurations, a computer may 
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not be present. Even in such configurations, the devices within the network are fully 
capable of interacting with each other on a peer basis. It should be recognized that data, 
commands and parameters can be sent between all of the devices within the IEEE 1394- 
1995 network, as appropriate. 
5 A block diagram of a hardware system resident in the AVHDD of the preferred 

embodiment of the present invention is illustrated in Figure 5. The AVHDD 60 preferably 
includes an IEEE 1394-1995 serial bus interface circuit 62 for sending communications to 
and receiving communications from other devices coupled to the IEEE 1394-1995 serial 
bus network. The interface circuit 62 is coupled to an isochronous data pipe 66. The 

10 isochronous data pipe 66 includes a register file 64. The isochronous data pipe 66 is 

coupled to a buffer controller 68. The buffer controller 68 is also coupled to a random 
access memory circuit 70 and to a read/write channel circuit 72. The read/write channel 
circuit 72 is coupled to media 74 on which data is stored within the AVHDD 60. The 
read/write channel circuit 72 controls the storage operations on the media 74, including 

1 5 reading data from the media 74 and writing data to the media 74. 

The AVHDD 36 preferably implements both the FCP protocol for recording 
isochronous data and the SBP-2 protocol for recording asynchronous data. The AVHDD 
of the present invention also permits data previously recorded in either the isochronous or 
asynchronous format to be read using either the FCP protocol or the SBP-2 protocol. 

20 The AVHDD of the present invention, if coupled to a controller capable of 

recognizing an AVHDD subunit and implementing the corresponding AV/C Command Set, 
will behave in all aspects as an AVHDD subunit. The controller, if using only the 
AVHDD subunit AV/C Command Set and the FCP protocol, will not know fliat the 
AVHDD of the present invention is anything other than a compliant AVHDD subunit. 

25 In addition, the AVHDD of the present invention implements the SBP-2 protocol 

and a suitable industry standard command set for accessing hard disk drives. The AVHDD 
of the present invention recognizes the conventional ORBs of the SBP-2 protocol as 
discussed above. The AVHDD of the present invention also recognizes a modified 
management ORB having a format as illustrated in Figure 6. The modified management 

30 ORB of the present invention includes the notify bit n and the request format field rq_fint, 
which are unchanged and defined as discussed above. As described above, the function 
field specifies the management fiinction requested. Within the modified management ORB 
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of the present invention, the function field contains a value not previously specified by the 
SBP-2 standard which indicates that this management ORB is requesting a manage 
asynchronous space function. Preferably, this value for the function field indicating a 
manage asynchronous space function is one of the values, reserved by the SBP-2 protocol 
for future standardization. 

Within the modified management ORB of the present invention, a sub-function field 
is included. Preferably, the sub-function field is a 16-bit field. Alternatively, the sub- 
function field has any appropriate number of bits. The sub-fimction field exists for the 
manage asynchronous space ORB and indicates what type of manage asynchronous space 
operation is requested, as defined by the functions listed below in Table III. 



15 



Value 


Operation Requested 


Sub-Function Dependent Field 


0 


Create Asynchronous Space 


Size Request (in LBAs) 


1 


Delete Asynchronous Space 


Asynchronous Space Number 


2 


Query Asynchronous Space 


Not Used 


3-FF 


Reserved Values 





A sub-function field value of "0" indicates a create asynchronous space operation request, 
20 A create asynchronous space operation request requests the target device to create an 

asynchronous space of the size contained in the sub-function dependent field. This size is 
expressed in units of logical blocks. The response block for this sub-function preferably 
contains the status of the operation, indicating whether the operation succeeded or failed. 
If the response block indicates that the operation succeeded, then the response block also 
25 contains the integer number of the newly created asynchronous space. If the response 
block indicates that the operation failed, then the response block also contains the total 
number of logical block addresses which can be assigned to an asynchronous space. In 
alternative embodiments, the response block to a create asynchronous space management 
ORB contains additional appropriate information. 
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When assigning integer numbers for asynchronous spaces, the target device assigns 
the numbers from the same space used for AV/C Command Set defined track numbers. 
During operation, the target device ensures that no asynchronous space has the same 
number as an AV/C track. 
5 A sub-function field value of "1" indicates a delete asynchronous space operation 

request. A delete asynchronous space operation request requests the target device to delete 
the asynchronous space corresponding to the number of the asynchronous space specified in 
the sub- function dependent field. The response block for this sub-function preferably 
contains the status of the operation, indicating whether the operation succeeded or failed. 
10 A sub-function field value of "2" indicates a query asynchronous space operation 

request. A query asynchronous space operation request requests the target device to return 
the integer numbers of currently existing asynchronous spaces. The data returned for a 
query asynchronous space request has the format illustrated below in Table IV. 



15 



20 



Number Of Asynchronous Spaces 



Asynchronous Space Number 



Asynchronous Space Number 



Asynchronous Space Number 



Table IV 



Within the data returned for a query asynchronous space request, the first quadlet contains 
the number of currently existing asynchronous spaces, followed by that many quadlets. 
Each succeeding quadlet then contains the number of an existing asynchronous space. 

25 When receiving a command block ORB for an operation request to be performed in 

an asynchronous space, the AVHDD of the present invention uses the request format field 
rq_j5nt within the command block ORB to determine within which asynchronous space the 
operation is to be performed. If the request format field rq_fint within the conmiand block 
ORB includes a value of "0" then the operation is treated as a conventional asynchronous 

30 access request and performed within the numerically lowest asynchronous space. If the 
request format field rq__fmt within the command block ORB includes a value of "1" then 
the operation is performed within the existing asynchronous space corresponding to the 
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number indicated within the asynchronous space number field in the command block ORB. 
Such commands operate on the specified asynchronous space number according to the 
details of operation of the command contained in the ORB following the asynchronous 
space number. 

5 On the AVHDD of the present invention, asynchronous spaces are logically 

contiguous storage areas which are accessed as a flat address space organized as logical 
blocks. Each asynchronous space begins with a logical block address (LBA) "0" and 
continues in a contiguous flat address space to the final LBA of the asynchronous space. 
The value of this final LBA depends on the size of the asynchronous space. 

10 Preferably, the AVHDD 36 of the present invention prevents an AV/C command 

from modifying any portion of an asynchronous space. However, the AVHDD will 
attempt to transmit data within an asynchronous space using the AV/C Command Set and 
the FCP protocol if an AV/C command is received that specifies a track number which is 
the same as the number of an existing asynchronous space. In this case, the AVHDD treats 

15 this asynchronous space as if it were an AV/C track and attempts to play the data within 
this asynchronous space according to the rules of the AV/C play command. The initiator 
that stored the content contained in this asynchronous space is responsible for ensuring that 
the data contained within the asynchronous space is of a format that, if played, results in a 
meaningful audio/video isochronous stream. 

20 An SBP-2 initiator device can also direct read or write commands to an AV/C track 

on the AVHDD of the present invention. To do so, the initiator places a valid AV/C track 
number in the asynchronous space field of a command ORB containing a value of "1" in 
the request format field rqLfmt. In this case, the AVHDD uses the LBA in the command 
in the ORB and addresses the AV/C track as if it were an asynchronous space. While 

25 preferably, no asynchronous space is modified by an AV/C command, an AV/C track can 
be modified by commands delivered according to the SBP-2 protocol. An AV/C track 
which is modified by SBP-2 protocol delivered commands retains its ability to be played or 
modified using AV/C commands. Preferably, the AVHDD of the present invention does 
not allow a copy-protected AV/C track to be accessed using SBP-2 protocol commands. 

30 An SBP-2 initiator device can also direct the AVHDD of the present invention to 

play, isochronously, a portion of an asynchronous space using a modified ORB. This 
modified ORB contains a pointer to a logical block address (LBA) scatter/gather list, which 
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is preferably located in the initiator's address space and read by the AVHDD. This 
scatter/gather list describes that portion of the asynchronous space to be read or written by 
isochronous data. 

In operation, an initiator device, such as the personal computer 20, can configure 
5 the AVHDD 36 for asynchronous access operations using the modified management ORB 
of the present invention. Using the manage asynchronous space management ORB as 
described above, an initiator can create, delete and obtain information about asynchronous 
spaces on the AVHDD 36. To create an asynchronous space on the AVHDD 36, the 
initiator sends a manage asynchronous space management ORB to the AVHDD 36 with a 

10 value of "0" in the sub-function field, requesting the AVHDD 36 to create an asynchronous 
space of the size indicated in the sub-fiinction dependent field. When the AVHDD 36 
receives such a create asynchronous space request, the AVHDD 36 determines if there is an 
unused continuous space on the AVHDD 36 of the size requested. If so, then the AVHDD 
36 creates the asynchronous space and assigns it a unique number. If there is not an 

15 unused continuous space of the size requested, then the AVHDD 36 sends a response block 
to the initiator indicating that the asynchronous space could not be created. 

To delete a previously created asynchronous space, the initiator sends a manage 
asynchronous space management ORB to the AVHDD 36 with a value of "1" in the sub- 
function field requesting the AVHDD 36 to delete the asynchronous space corresponding to 

20 the number contained within the sub-function dependent field. When the AVHDD 36 

receives such a delete asynchronous space request, the AVHDD 36 deletes the appropriate 
asynchronous space. 

To determine the amount and numbers of existing asynchronous spaces, the initiator 
sends a manage asynchronous space management ORB to the AVHDD 36 with a value of 
25 "2" in the sub-function field requesting the AVHDD 36 to return the numbers of existing 
asynchronous spaces. When the AVHDD 36 receives such a query asynchronous space 
request, the AVHDD 36 determines the existing asynchronous space nimibers and returns 
them to the initiator. 



30 response to a command ORB from an initiator, such as the personal computer 20. The 

asynchronous data can originate form any device within the network of devices coupled to 
the AVHDD 36. When receiving a command ORB requesting a write operation, the 



Asynchronous data is stored within an asynchronous space in the AVHDD 36 in 
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AVHDD 36 determines the value of the request format field rcLfmt in the command ORB. 
If the request format field rq_fmt includes a value of "0" then the write operation is 
performed and the data written within the numerically lowest asynchronous space in the 
AVHDD 36. If the request format field rq_fint includes a value of "1" then the storage 
5 operation is performed and the data written within the asynchronous space corresponding to 
the number indicated within the asynchronous space number field in the command ORB. 

Isochronous data is stored m the AVHDD 36 in response to an AV/C record 
command firom a controlling device. The isochronous data can originate from any device 
within the network of devices coupled to the AVHDD 36. When receiving an AV/C 
10 record command, the AVHDD 36 records the isochronous data fi-om the appropriate 
isochronous channel in an AV track as discussed above. Preferably, the AVHDD 36 
prevents an AV/C command from modifying any portion of an asynchronous space. 
However, an SBP-2 initiator device can direct write commands to an AV/C track on the 
AVHDD 36- 

15 Data is transmitted from the AVHDD 36 to other devices on the network of devices 

coupled to the AVHDD 36 in response to both an AV/C play command and a command 
ORB. When the AVHDD 36 receives an AV/C play command specifying an isochronous 
track number that track is transmitted per the AV/C Command Set and the FCP protocol. 
When the AVHDD 36 receives an AV/C play command specifying a track number which 

20 is the same as the number of an existing asynchronous space, the AVHDD 36 treats this 
asynchronous space as if it were an AV/C track and attempts to play the data within this 
asynchronous space according to the rules of the AV/C play command. 

When the AVHDD 36 receives a command ORB firom an SBP-2 initiator device 
requesting a read operation, the AVHDD 36 first determines the value of the request 

25 format field rq_fmt. If the request format field TqJmX has a value of "0" then the read 
operation is performed from the lowest numbered asynchronous space. If the request 
format field rq_fmt has a value of "1" then the read operation is performed fi-om the space 
corresponding to the number within the asynchronous space field. This number can 
correspond to either an asynchronous space or AV track. 

30 In the manner described herein, data can be recorded and retrieved in the AVHDD 

36 in an isochronous format using the AV/C Command Set and the FCP protocol and in an 
asynchronous format using the SBP-2 protocol. A modified management ORB within the 
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SBP-2 protocol is used to create, delete and obtain information about asynchronous spaces 
within the AVHDD 36. Isochronous data accesses can be performed in the AVHDD 36 on 
both the AV tracks and data within an asynchronous space. Preferably, an AV/C command 
cannot be used to write data within an asjoichronous space. Asynchronous data accesses 
5 can be performed in the AVHDD 36 within both asynchronous spaces and AV tracks. 

The present invention has been described in terms of specific embodiments 
incorporating details to facilitate the understanding of principles of construction and 
operation of the invention. Such reference herein to specific embodiments and details 
thereof is not intended to limit the scope of the claims appended hereto. It will be 

10 apparent to those skilled in the art that modifications may be made in the embodiment 
chosen for illustration without departing from the spirit and scope of the invention. 
Specifically, it will be apparent to those skilled in the art that while the preferred 
embodiment of the present invention is used with an IEEE 1394-1995 serial bus structure, 
the present invention could also be implemented on any other appropriate bus structures. 

15 Additionally, it will also be apparent that while the preferred embodiment of the present 
invention is implemented within an AVHDD, any other appropriate media storage device 
can also be used. 
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CLAIMS 



I Claim: 



11. A method of accessing a media storage device coupled to one or more 

2 devices comprising the steps of: 

3 a. receiving a command from one of the one or more devices; 

4 b. determining if the command is one of an isochronous format command and 

5 an asynchronous format command; 

6 c. accessing the media storage device in an asynchronous format if the 

7 command is an asynchronous format command; and 

8 d. accessing the media storage device in an isochronous format if the command 

9 is an isochronous format conunand. 



1 2. The method as claimed in claim 1 wherein the media storage device records 

2 data in the isochronous format in AV tracks and data in the asynchronous format in one or 

3 more asynchronous spaces. 

1 3. The method as claimed in claim 2 wherein the isochronous format conunand 

2 is an AV/C command according to FCP protocol 

1 4. The method as claimed in claim 2 wherein the asynchronous format 

2 command is delivered according to SBP-2 protocol. 

1 5. The method as claimed in claim 1 wherein the asynchronous format 

2 command is dehvered according to SBP-2 protocol. 

1 6. The method as claimed in claim 5 wherein the asynchronous format 

2 command includes an operation request block. 
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1 7. The method as claimed in claim 6 wherein the operation request block is 

2 associated with a scatter/gather list describing portions of asynchronous space on the media 

3 storage device to be read or written by isochronous data. 

1 8. The method as claimed in claim 1 further comprising the step of creating an 

2 asynchronous space within the media storage device in response to receiving a manage 

3 asynchronous space request requesting creation of the asynchronous space. 

1 9. The method as claimed in claim 8 further comprising the step of deleting a 

2 previously created asynchronous space within the media storage device in response to 

3 receiving a manage asynchronous space request requesting deletion of the previously 

4 created asynchronous space. 

1 10. The method as claimed in claim 1 wherein the media storage device is a 

2 hard disk drive. 

1 11. The method as claimed in claim 1 wherein communication between the 

2 media storage device and the one or more devices substantially complies with a version of 

3 the IEEE 1394 standard. 

1 12. A media storage device for storing and retrieving data received from one or 

2 more devices in response to a command comprising: 

3 a. an interface circuit configured to couple to the one or more devices to 

4 commimicate with the one or more devices; 

5 b. a control circuit coupled to the interface circuit to determine if the command 

6 is one of an isochronous format command and an asynchronous format 

7 conamand; and 

8 c. media coupled to the control circuit to record isochronous data received from 

9 the one or more devices in an AV track in response to an isochronous record 

10 command, to record asynchronous data received from the one or more 

1 1 devices in an asynchronous space in response to an asynchronous write 
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12 command and to retrieve both previously recorded asynchronous data and 

13 isochronous data. 

1 13, The media storage device as claimed in claim 12 wherein the isochronous 

2 format command is an AV/C command according to FCP protocol. 

1 14. The media storage device as claimed in claim 12 wherein the asynchronous 

2 format command is delivered according to SBP-2 protocol. 

1 15. The media storage device as claimed in claim 12 wherein an asynchronous 

2 space is created on the media in response to a manage asynchronous space request 

3 requesting creation of the asynchronous space received from one of the one or more 

4 devices. 

1 16. The media storage device as claimed in claim 12 wherein the media storage 

2 device is a hard disk drive, 

1 17. The media storage device as claimed in claim 12 wherein the interface 

2 circuit is coupled to the one or more devices through a network which substantially 

3 complies with a version of the IEEE 1394 standard. 

1 18. A management operation request block for requesting a manage 

2 asynchronous space operation within a media storage device comprising: 

3 a. a function field including a first value indicating that the operation request 

4 block is a manage asynchronous space operation request block; and 

5 b. a sub- function field including a second value indicating a type of manage 

6 asynchronous space request requested in the management operation request 

7 block, 

1 19. The management operation request block as claimed in claim 18 wherein the 

2 type of manage asynchronous space request is a selective one of a create asynchronous 

3 space request, a delete asynchronous space request and a query asynchronous space request. 
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1 20. The management operation request block as claimed in claim 19 wherein an 

2 asynchronous space is created on the media storage device in response to a manage 

3 asynchronous space request of the type create asynchronous space. 

1 21. The management operation request block as claimed in claim 19 wherein an 

2 existing asynchronous space is deleted on the media storage device in response to a manage 

3 asynchronous space request of the type delete asynchronous space. 

1 22. The management operation request block as claimed in claim 19 wherein 

2 information about existing asynchronous spaces on the media storage device is obtained in 

3 response to a manage asynchronous space request of the type query asynchronous space, 

1 23. The management operation request block as claimed in claim 18 further 

2 comprising a notify bit and a request format field. 

1 24. The management operation request block as claimed in claim 18 wherein the 

2 management operation request block has a format which substantially complies with SBP-2 

3 protocol. 

1 25. The management operation request block as claimed in claim 18 wherein the 

2 media storage device is a hard disk drive. 

1 26. A method of accessing a media storage device coupled to one or more 

2 devices within a network of devices comprising the steps of: 

3 a. receiving a command from one of the one or more devices; 

4 b. determining if the command is one of an isochronous AV/C format 

5 conamand according to FCP protocol and an asynchronous format command 

6 received according to SBP-2 protocol; 

7 c. accessing the media storage device in an asynchronous format according to 

8 the SBP-2 protocol if the command is an asynchronous format command; 

9 and 
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10 d. accessing the media storage device in an isochronous format according to the 

1 1 FCP protocol if the command is an isochronous format command. 

1 27. The method as claimed in claim 26 further comprising the step of storing 

2 isochronous data in response to a record isochronous format command within an AV track 

3 in the media storage device. 

1 28. The method as claimed in claim 26 further comprising the step of creatmg 

2 an asynchronous space within the media storage device in response to receiving a manage 

3 asynchronous space request requesting creation of the asynchronous space. 

1 29. The method as claimed in claim 28 further comprising the step of storing 

2 asynchronous data in response to a write asynchronous format command within the 

3 asynchronous space. 

1 30. The method as claimed in claim 28 further comprising the step of deleting 

2 an existing asynchronous space within the media storage device in response to receiving a 

3 manage asynchronous space request requesting deletion of the existing asynchronous space. 

1 31. The method as claimed in claim 26 further comprising the steps of: 

2 a. determining if the command is one of an isochronous format command 

3 received according to a modified SBP-2 protocol; and 

4 b. accessing the media storage device in an isochronous format if the command 

5 is received according to the modified SBP-2 protocol and requests 

6 isochronous handling. 

1 32. The method as claimed in claim 31 further comprising the step of storing 

2 isochronous data in response to a command received according to the modified SBP-2 

3 protocol. 

1 33. The method as claimed in claim 26 wherein the media storage device is a 

2 hard disk drive. 
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34. The method as claimed in claim 26 wherein communication between the 

network of devices substantially complies with a version of the IEEE 1394 standard. 



1 35. A network of devices comprising: 

2 a. one or more content devices for generating and consuming content data; and 

3 b. a media storage device coupled to the one or more content devices for 

4 storing and retrieving the content data in response to a command, including: 

5 i. an interface circuit coupled to the one or more content devices 

6 to transmit communications to and receive communications 

7 from the one or more content devices; 

8 ii. a control circuit coupled to the interface circuit to determine if 

9 the command is one of an isochronous format command and 

10 an asynchronous format command; and 

1 1 iii. media coupled to the control circuit to record isochronous data 

12 received from the one or more content devices in an AV track 

13 in response to an isochronous record command, to record 

14 asynchronous data received from the one or more content 

15 devices in an asynchronous space in response to an 

16 asynchronous write command and to retrieve both recorded 

17 asynchronous data and isochronous data. 

1 36. The network of devices as claimed in claim 35 further comprising a 

2 controller coupled to the interface circuit and to the one or more content devices for 

3 generating the command and transmitting the command to the interface circuit. 

1 37. The network of devices as claimed in claim 35 wherein the command is 

2 received from one of the one or more content devices. 

1 38, The network of devices as claimed in claim 35 wherein the isochronous 

2 format command is an AV/C command according to FCP protocol. 
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1 39. The network of devices as claimed in claim 35 wherein the asynchronous 

2 format command is delivered according to SBP-2 protocol. 

1 40. The network of devices as claimed in claim 35 wherein an asynchronous 

2 space is created on the media in response to a manage asynchronous space request 

3 requesting creation of the asynchronous space received from one of the one or more 

4 content devices. 

1 41. The network of devices as claimed in claim 35 wherein the media storage 

2 device is a hard disk drive. 

1 42. The network of devices as claimed in claim 35 wherein the interface circuit 

2 is coupled to the one or more content devices through a network which substantially 

3 complies with a version of the IEEE 1394 standard. 
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